This redaction is poorly targeted, and unlikely to accomplish what is intended.

We blindly redact a certain asset's Name and Description, regardless of whether they contain the sensitive text.

The customer intended for the entire story to be permanently removed, as if it never existed in the first place, including any possible non-sensitive historical values. Customer agreed to text content redaction as a proxy for complete removal of the story in question.

* The sensitive text may be on other fields.

Indeed, that was one outstanding question we still need to ask.

* The sensitive text may occur in historical variations of the current text.

Not sure what you mean. The redaction occurs historically against all Name and Description variants referenced by BaseAsset.

* An innocent Name value may be shared with other assets.

Possibly, if the story in question was ever named as something other than what is now sensitive content, and another story ever happened to share that original name. While we can detect string value being shared across multiple assets, we have no practical way of establishing its innocence.

I believe we should target text based on a pattern that the user supplies.

The customer was unwilling to disclose any information about the sensitive content to be redacted.

The customer intended for the entire story to be permanently removed, as if it never existed in the first place, including any possible non-sensitive historical values. Customer agreed to text content redaction as a proxy for complete removal of the story in question.

I seriously doubt they intended that. Rather, I suspect, that was their "solution" to their sensitive data disclosure problem.

Are they imagining that related Tasks and Tests will go too? We don't know, it hasn't been asked. Our shared understanding is nowhere near treating this request as a specification.

Agreeing to text redaction is a strong clue that "sensitive data exposure" is the real problem, not "the existence of this story". This customer will likely be pissed if we do this "because that's what they asked for" but it doesn't eliminate sensitive data in their database.

• The sensitive text may be on other fields.

Indeed, that was one outstanding question we still need to ask.

The user may have no good way of tracking down all the fields, indeed all the assets or tags or activities, where what they want gone occurs. They may not even have a good way of understanding what we're asking about. We know our data model and they don't, so what they say and what we hear are 2 different things (and vice versa).

• The sensitive text may occur in historical variations of the current text.

Not sure what you mean. The redaction occurs historically against all Name and Description variants referenced by BaseAsset.

I see 👍🏼, Yes, it is historical.

• An innocent Name value may be shared with other assets.

Possibly, if the story in question was ever named as something other than what is now sensitive content, and another story ever happened to share that original name. While we can detect string value being shared across multiple assets, we have no practical way of establishing its innocence.

I believe we should target text based on a pattern that the user supplies.

The customer was unwilling to disclose any information about the sensitive content to be redacted.

They do not have to disclose it, they will be editing and running the script locally.